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Configuration Requirements Component Specification 


INTRODUCTION AND OVERVIEW 
BACKGROUND 


The development of the LAN Facility for Release 4.0 of MOD400 
established certain requirements that have to be provided during 
MOD400 startup and at initialization time of the LAN Controller. 
This specification describes what has been provided to meet those 
requirements. 


BASIC PURPOSE 


The LAN Facility requires its own specialized processing at CLM time 
to scan user-supplied, LAN specific directives and establish the 
appropriate data structures and system linkages consistent with those 
directives, that are necessary for proper execution. 


Some additional processing is required when the LACS (Local Area 
Controller Subsystem) environment has to be initialized. At that 
time, a special configuration file is processed to complete the LAN 
startup and initialization process. 


BASIC STRUCTURE 


MOD400 conventions for CLM extension modules call for a bound unit 
structure which has a root module containing a directory of the LAN 
CLM directive names, and 2 floating overlay modules which contain the 
processing logic required by the directives. The lst overlay 
contains interpretive processing logic for the directives; the 2nd 
overlay finalizes the processing. 


Post CLM processing of the Configuration File will be packaged as 
part of the System Management functionality resident in the Lé6é. 


BASIC OPERATION 


This module will be executed in much the same fashion as is any 
extension to the Configuration Load Module function of MOD400. After 
the root module is loaded, it is linked with other CLM extension root 
modules. LAN specific CLM directives are then processed by the lst 
phase with parameter information stored off in temporary structures. 
The 2nd phase is then loaded and final processing takes place with 
the construction of permanent control structures and the installation 
of BU's and tasks. 


The processing of the Configuration File directives will be keyed off 
of the lst Activate SAP ROQIO issued by the lst user application to 
establish an interface with the LAN Facility. At that time, the 
Configuration File will be OPEN'ed and directives will be read in and 
processed. This processing will result in the building and 
initializing of a small set of new data structures, and completing 
the initialization of CLM constructed data structures, 


Page -4- 


Configuration Requirements Component Specification 


EXTERNAL SPECIFICATION 
OWNED DATA STRUCTURES 


Although this component is responsible for building a number of 
control data structures, they are not considered as owned by the 
component. Ownership of these structures will be assumed by the LACS 
Driver since the Driver is the primary user. Refer to Ref. [8] for a 
description of these structures, 


EXTERNAL INTERFACES 


This component will implement a collection of external interfaces 
that will call the standard CLM provided functions. These standard 
functions (currently there are 22 provided) are in place to supply 
common services to the various MOD400 CLM extension modules. These 
functions are very briefly described here. They are covered again in 
more detail in Section 3.0, the Internal Specification, of this 
document. | 


Function No. Function Description 
0 Get next parameter from directive 
2 Validate directive parameters 
3, 4 & 20 Get temporary or permanent memory 
5 Report errors 
11 Build Resource Control Table 
17 Request free lrn 
22 Locate controller table 


Additionally, the LAN CLM extension module will execute the Spawn 
Task MCL on each occasion requiring the installation oF. an interrupt 
task for processing controller interrupts. 


Initially, the LAN Facility will require no special functions in its 
interface with Release 4.0's load balancing algorithn. Basically, as 
each LACS controller is recognized, the LAN CLM extension module 
calculates its weight based on the number of adapters attached, and 
communicates this information to the central CLM module by way of 
Function call no. 22. After all controllers have been reported, load 
balancing takes place and controllers are allocated to processors. 
Now, aS Request tasks are created for servicing user requests issued 
to the LAN, they will be set up to execute on the same processor that 
the respective controller to which these requests will be issued, was 
assigned. A controller asSigned to a specific processor will be 
instructed to direct its interrupts to that processor; consequently, 
an interrupt task for processing those interrupts will be set up to 
execute on that processor. 
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2.6 


This arrangement essentially allocates an entire controller to a 
processor. Later refinements may allow, under certain configuration 
conditions, the allocation of a protocol layer instance to a 
processor. 3 

Where multiple processors exist in a configuration, an interrupt task 
installed to execute on 1 processor will have its hardware level 
reserved on all the processors. This is a MOD400 convention for 
meeting resiliency requirements. 


INITIALIZATION REQUIREMENTS 

TBS. 

TERMINATION REQUIREMENTS 

This component has no special termination requirements. 

ENV IRON MENT 

Systems environment is MOD400/Release 4.0 and its successors. 

TIMING AND SIZE REQUIREMENTS 

Not applicable. 

ASSEMBLY AND LINKING 

This component will be implemented in L6 Assembly language and will 

use normal Assembly and Linker functions to prepare the CLM BU and 

the Configuration File processing module. 
The CLM BU will be named ZQLCLM; it will be made up of 3 modules, 
ZQLCRT (the root module), ZQLCP1l (Phase 1 overlay) and ZQLCP2 
(Phase 2 overlay. 
The Configuration Processing module will be named SMCNFG and will 
be 1 of a number of modules linked together to make up the L6 LAN 
Manager BU, ZQLMGR. 

TESTING CONSIDERATIONS 

This component will be tested in a development environment to ensure 

correct operation. Ability to detect incorrect input and incorrect 

input sequences will be verified. Additionally, the component's 

ability to generate correct data structures and task instances at 


their specified priority levels and in the appropriate processors 
based on configuration directives will be verified. 
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2-9 DOCUMENTATION CONSIDERATIONS 


Information relating to LAN configuration requirements will be 
contained in a number of documents: 


© component specification (this document) to convey development 
and maintenance information; 


o Software Maintenance Document (SMD) to provide ae primary 
software maintenance reference for the LAN Facility; 


oO MOD400 Manual on System Building and Administration (CZ02). 
2.10 OPERATING PROCEDURES 


LAN related directives, as defined in this section, are in 2 
categories; CLM directives and Configuration File directives. CLM 
directives are to be included in the CLM_USER file and are processed 
by MOD400's Configuration Load Manager at system startup time. 
Configuration File directives are included in a standard sequential 
file and are processed after system startup by LAN System Management 
coincident with the lst Activate SAP MCL issued by a user 
application. 


2.10.1 LAN CLM Directives 


TLIN, These directive names describe the presence of a layer 

NLIN, instance, which means that a protocol layer entity 

LLIN, of the type and instance specified in the directive will 

ML IN be configured in the LACS. This layer instance is being 
configured to provide its service to one or more user 
applications as defined by the following LCLUSR 
directive(s). 


TLIN specifies a Transport protocol layer instance; 

NLIN specifies a Network protocol layer instance; 

LLIN specifies a Link protocol layer instance; 

MLIN specifies the existence of the System Management 
layer instance. 


LCLUSR Describes a user application interface to the protocol 
service described by the preceding layer instance 
directive. One occurrence of this directive is required 
for each such user interface desired. 


Page -7- 


LAN Configuration Requirements Component Specification 


e Layer Instance Directive 


This directive causes a number of control structures to be generated 
for managing and Supporting the user interface(s) to this layer 
instance, An interrupt task is also created and installed at the 
priority level specified in the directive to process request 
completions being returned by the layer entity. 


Format: 
TLIN symb_name, protocol type,chan_no,pl_ addr,int level 
NLIN 
LLIN 
ML IN 


Argument Description: 
symb_ name | 
A name assignment through which this layer entity can be known and 
referenced. Since a layer instance defined in CLM also has to be 
defined in the Configuration File, this name must match its 
counterpart directive in the Configuration File. 


Note: 
In all cases where the ‘'symb_name' parameter is used, maximum 
length will be 16 characters, and allowable values will be 


'A-Z', '0-9' and '_'. ; 
~ protocol type 
( Represents a particular protocol entity implemented for a layer. 


For example, the Network layer could have 2 protocol types 
implemented, a connectionless protocol and a sub-network protocol 
for DSA X.25 support. The particular type would be specified by 
this parameter, i.e., '‘cnls' for the connectionless protocol and 
‘snap’ for the sub-network protocol. Currently, the protocol 
types that have been defined are as follows: 


Management layer ‘mgmt' (System Management) 


Transport layer ‘cls4' (ISO Class4 protocol) 
Network layer ‘clns' (connectionless network protocol) 
Network layer ‘snap’ (sub-network protocol for supporting 
DSA's X.25 network protocol 
Link layer ‘typl' (Type 1 connectionless protocol) 
chan_no 


The base channel number of the LACS controller that this layer 
instance resides in. A 4 hex digit field in the form "X'hhhh'" 
will be used this parameter. The 3 rightmost hex digits will 
always be "000"; the leftmost hex digit will be specified in the 
range 1 thru F. 


pl_addr 
This field is applicable only when the layer instance directive is 
describing a link layer instance. In this case, it specifies the 


a address or position of the physical line on the controller. This 
( parameter is specified as a decimal value in the range of 0 thru 
a 
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int_level | 


The hardware priority level at which will be installed an. 


interrupt handler task for processing the interrupts generated by 
this layer instance entity in the LACS as it completes a request. 
This parameter will be specified as a decimal value, most probably 
in the range between 10 and 40. As a general guideline, the 
interrupt level for a LACS controller should be lower, i.e., a 
higher number, than other controller interrupt levels. 


Local User Directive 


This directive specifies that a local user application in the node 
being configured will be interfacing with the LAN Facility and 
specifically with the layer entity identified by the immediately 
preceding layer instance directive. A local user is regarded by the 
LAN Facility as an application entity availing itself of LAN services 
through a mechanism called a service access point (SAP). More than l 
local user may be configured as uSing the services of the layer 
instance, in which case, a SAP will be established for each of the 
users. The directive results in a Resource Control Table structure 
(RCT) being built on behalf of this local user. The RCT has a LAN 
specific extension area attached to it which is initialized by the 
LAN CLM process. An lrnis also allocated to this user. 


Format: 
LCLUSR symb_ name, req_level 


Argument Description 
symb name 
A name assignment that is used for associating a particular MOD400 
user entity with a service access point into the LAN Facility. 
This name is used during the initial association dialogue, as an 
argument in the Associate Local User MCL. 


req level 


This value represents the hardware priority level at which request 
processing initiated by this LAN user will be executed. 


Page -9- 


a 


C 


LAN Configuration Requirements Component Specification 


2.10.2 LAN Configuration File Directives 


These directives are described in 2 Component Specifications; this 
one and the specification for System Management. They are provided 
in both documents for ease of reading and comprehension. The set of 
Configuration File (C-F) directives consist of the following: 


Controller Directive 


This directive is optional and may be used to override defaulted 
parameters for flow control of read and write operations and for 
specifying no. of retries when an IOLD instruction is nak'd. 


Format: : 

CTLR symb_ name, addr,max_lcb,max_ios 

Argument Description 
symb name 
The symbolic name assigned to this controller; name is based on 
controller's megabus address, e.g, a controller with an address of 
"A000" will be named "lancta" where "lanct" is the constant part 
of the controller name. 


addr 

The base channel number of the controller; this parameter is 
specified as a single hex digit. In the example above, the base 
channel number of the controller would be "A". 


max_lcb 

Maximum number of lcb's allowed to be outstanding on this 
controller; specified as a 16 bit integer. Default value set to 
99. 


max ios 

Maximum number of retry attempts for executing IO or IOLD 
instructions when the controller is nak'ing the instruction. 
Default value set to 4. 
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Layer Instance Directive | | we 
This directive specifies an occurrence of a layer instance within the ~~ 
controller. Every layer instance described in CLM must also be 
described in the C-F. Additionally, any lower layer instance(s) 


which supports the CLM defined layer instance must also be described 
in the C-F. For example, a Link layer instance described in CLM is 
required to be described in the C-F along with the physical or MAC 
layer instance that is subordinate to and interfaces with the Link 
layer instance. 

Where a layer instance directive is described, it will be followed by 
the local and remote SAP directives that are being configured for 
that layer instance. 


Format : 

TLIN 

NLIN symb_ name,protocol type,chan_no,pl_ addr 
LLIN | 

PL IN 


Layer instance directives contained in the C-F are essentially the 
same as their CLM counterparts with the following exceptions: 


Interrupt level is not required; 

MLIN is not required in the C-F; 

pl_addr is applicable only when the layer instance directive is 
describing a link (LLIN) or physical (PLIN) layer instance. 

PLIN is required since 1 or more MAC layer instances must be 
configured; PLIN is not a CLM directive because user interface to ~~ 
MAC layer is not provided. 


Argument description is the same as described for CLM layer instance 
directive, 


Local SAP Directive 


This directive specifies a local SAP (LCLSAP) through which a service 
requestor at a higher layer will make requests of the service 
provider that is the layer instance to which this LCLSAP belongs. 
LCLSAP's at higher layers are linked with LCLSAP's at immediately 
subordinate layers by way of mapping information contained in the 
LCLSAP directive. This linkage or association establishes a path for 
incoming data up through the multiple layers at a node and thereby 
enables delivery of that data to the user. 


Format: 
LCLSAP symb_name,Mmapping, phys addr,flow_ctrl,attributes 


att 
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Argument Description 


symb_name 

A name assignment that will be used in referring to, or 
associating with this LCLSAP. Where the layer instance that this 
LCLSAP belongs to is also described in CLM (and is therefore a 
layer instance with an interface to a uSer application, i.e., an 
exposed layer instance), this LCLSAP directive will have a 
counterpart LCLUSR directive, and the symb_ name parameter must 
match the symb name parameter of the LCLUSR directive. Where the 
layer instance that this LCLSAP belongs to is not described in CLM 
(unexposed), this symb_name will most likely be named in a mapping 
context by a higher layer LCLSAP directive, and result in a 
downward associative link when that higher layer LCLSAP is 
activated. 


mapping | 

This parameter will be presented as 1 or more symbolic name 
elements where each element names a local SAP belonging to a layer 
instance at the next lower layer. Where more than 1 element is 
specified, the elements will be separated by a slash (/) 
character. A one-to-one or one-to-many downward mapping 
capability is therefore possible. For example, an LCLSAP 
directive being defined as belonging to a network layer instance 
would specify the name of an LCLSAP belonging to a configured link 
layer instance. That named link layer LCLSAP would be required to 
be configured. 


phys addr | 
Addressing information is specific to the layer in which the 
LCLSAP directive is being defined. Addressing conventions for 


LCLSAP's in each of three layers will be described nere., 


Link Layer , 

A LCLSAP address for link layer protocol is defined in IEEE 
802.2 as consisting of a LLC address field (8 bits) plus the 
MAC address (which may be either 16 or 48 bits). Because the 
LACS architecture establishes a one to one correspondence 
between a link layer instance and a physical layer instance (or 
MAC adapter), the MAC address implicitly becomes part of each 
LCLSAP address and is therefore included in the link layer 
LCLSAP address. 
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Network Layer | 
For the Null Network Protocol, which is our first. 
implementation, no addressing data is required. This parameter 
for a network layer LCLSAP would not be specified. 

Note: 


For the SNDCP sub-network protocol, a physical address would 
likewise not be required since there would be a one to one 
Mapping between a sub-network layer LCLSAP and a link layer 
LCLSAP. 


Discussion of network addresses in an Internetworking Protocol 
environment is deferred to a later time. 


Transport Layer 

Physical address for a transport layer LCLSAP is defined in ISO 
as consisting of a “transport selector" and a network LCLSAP 
address. 

Our current implementation Supports only 1 transport layer 
instance per controller and similarly, only 1 null network 
layer instance per controller. Only 1 network LCLSAP is 
required to be configured to support the transport entity, and 
as a result, a similar addressing situation is established 
between transport and network layer instances as exists between 
link and MAC layer instances. That is, the network LCLSAP 
address implicitly becomes part of each transport LCLSAP 
address and is therefore included with the transport selector ~-. 
value. | 
The transport selector portion of the address simply identifies 
the transport service user (DRMO, ISO Session, Fasttrack) and 
will be specified as a decimal integer. The network LCLSAP 
address will be specified according to our own internal 
conventions (since no standards exist for a null network 
protocol), and could also be specified as a decimal integer. 


flow_ctrl 
To be supplied 


attributes 
To be supplied 


Remote SAP Directive 


This directive describes a remote peer entity with which a local user 
of the layer instance wishes to communicate. REMSAP's at higher 
layers are linked with REMSAP's at immediately subordinate layers by 
way of mapping information contained in the REMSAP directive, similar 
to the manner in which LCLSAP's are linked. This linked sequence of 
REMSAP's is effectively established when a user application issues an 
Activate REMSAP RQIO. The linkage establishes a path for outgoing 
data and allows the identification of remote peers at each layer so 
that correct remote addresses can be formatted into the message ~. 


e 


header. | | 2 
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Format: 
REMSAP symb name, mapping, phys addr,flow_ctrl,attributes 


Argument Description 

symb_name 

A name assignment that will be used in referring to, or 
associating with this REMSAP. If the layer instance to which this 
REMSAP belongs has a direct interface with a user application, 
this symb name will be used in an Activate REMSAP RQIO issued by 
the application. If the layer instance to which this REMSAP 
belongs is a subordinate layer, this parameter will be used in an 
internal association context, as described earlier. 


mapping | 
This parameter will be presented as 1 or more symbolic name 
elements where each element names a remote SAP belonging to a 
layer instance at the next lower layer. Where more than 1 element 
is specified, the elements will be separated by a slash (/) 
character. A one-to-one or one-to-many downward mapping 
capability is therefore possible. In the normal case, a Single 
name element is named in this parameter to specify the next 
downward step in the outward path for a message. 

The network layer represents a special case for specifying this 
information in a network REMSAP directive. When Internetworking 
Protocol is implemented and routing options and decisions are 
possible, this parameter could specify multiple downward mappings 
naming different subordinate REMSAP's, This one-to-many mapping 
feature of the IP entity allows the configuring of more than 1 
path to the same end point, and implies that -.the IP entity will 
make the decision as to which path to choose, 


phys addr 

As described earlier for LCLSAP address specification, the format 
and content of this parameter is unique to the layer to which the 
REMSAP belongs. : 

For a Link layer REMSAP, the address consists of both the remote 
LLC address and the remote MAC address, specified in the same 
format as described for a Link layer LCLSAP. 

For the Null Network protocol, no addressing information is 
required. For the SNDCP sub-network protocol, no addressing 
information is required as well. Because of the one-to-one 
relationship between SNDCP layer instance and Link layer instance 
in our architecture, the subordinate Link layer REMSAP address 
would insure delivery to the correct remote SNDCP peer entity. 

The Transport layer REMSAP address will be specified as a 
transport selector field and a network REMSAP as described for a 
transport layer LCLSAP. 
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flow _ctrl 
To be supplied. 


attributes 
To be supplied. 


2.10.3 Example of a LAN Configuration 


The following example illustrates the use of CLM and C-F directives 
in describing a LAN configuration. 


The example describes a single user application that is to interface 
with the Type 1 connectionless link layer protocol and desires to 
communicate with 2 remote users. A single LACS controller with a 
single CSMA/CD adapter is to be configured. 


CLM Directives 


LLIN clsll,typl,X'C',2,14 
LUSR rfal,16 


These two directives specify that a Type 1 link layer instance 
Supporting a single user is to be installed in the LACS . The 
base channel number of the controller is "C", i.e., the megabus 
address is "C000", and the adapter, or physical line, that this 
link layer is to interface with is assigned position number 2 on -. 
the controller. An interrupt task at H/W priority level 14 is to. | 
be installed on the L6 processor for processing interrupts from ~ 
this layer instance on this controller. 


The single user interfacing with the connectionless Type 1 service 
will be assigned a system name of "rfal". The user will also be 
assigned an lrn and a request processing task will be installed at 
H/W priority level 16 for processing requests to the LACS Driver. 


Configuration File Directives 


LLIN clsll,typl,X'C!',2 

LCLSAP rfal,abcd,x'01',xX'0004' 
REMSAP rlul,,X'01',xX'0003'! 
‘REMSAP rlu2,,X'01',xX'0002' 


PLIN ethrnt,csma,X'C' ,2 
LCLSAP abcd,,xX'0004' 


The LLIN directive should have an identical counterpart in the CLM 
directive set; this is so because the layer instance being 
described is being configured to support a user interface and has 
to be described in both places. 
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1 local SAP and 2 remote SAP's are specified as belonging to the 
Link layer instance. Since the link layer instance in this 
configuration supports a direct user interface, the local SAP 
directive is the representation of that interface. The symbolic 
name specified in this directive is therefore required to be the 
same as that specified for the LUSR directive in CLM. The mapping 
parameter establishes a link with the single local SAP, "abcd", 
belonging to the MAC layer instance. The 2 remaining parameters 
in this LCLSAP directive specify its full address consistent with 
IEEE 802 standards. In this example, a 16 bit station address 
(the 2nd of the 2 parameters) is assumed. 

The 2 remote SAP's, "rlul" and "rlu2" contain no mapping 
parameters because mapping is not required for remote SAP's at the 
link layer. The remote SAP address is declared in the same format 
as it is for the local SAP. 


The PLIN directive specifies that a MAC layer instance supporting 
CSMA/CD protocol is to be installed in the LACS. Controller and 
adapter address parameters are required to be the same as 
specified in the LLIN directive. 


The single local SAP directive for the MAC layer instance (there 
is only 1 allowed) simply specifies its name and, if desired, 
attributes of the MAC layer. 


Figure 2.1 illustrates the relationship of the entities described in 
this configuration. 
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( 2-11 ERROR MESSAGES 


To be supplied. 
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3.0 INTERNAL SPECIFICATION 


CLM Processin 


(301.1 System Initialization 


The bound unit ZQLCLM is comprised of 3 modules; a root module and 2 
floating overlay modules. The root module, as dictated by CLM 
extension module conventions, is a prescribed sequence of constants, 
displacements . and pointers that is used by the central CLM function 
to process. directives. When the root of this BU is loaded, it is 
Linked.. together. ‘with other root modules of CLM extensions. Included 
in the root is a directory of the LAN CLM directive names that this 
BU is responsible for processing. While in the lst phase of CLM 
processing, the lst overlay will be loaded to process all LAN CLM 
directives. Each directive type will have its own processing routine 
which will be invoked each time its respective directive is 
encountered. in the.CLM file. During the 2nd phase, the 2nd overlay 
is Toaded. © Each directive type will have its own processing routine 
in this overlay as well. However, during the 2nd phase, each of the 
processing -rqutines. are executed only once. 


3. 1. 2 Configuration. File Processing 


Processing of “the ‘Conf iguration File (C-F), which as described 
earlier, is a post-CLM function, will be performed by a module which 
will be incorporated into the LAN Manager BU (ZQLMGR). Its 


~ 
N 


invocation wil] .be triggered by the lst Activate SAP MCL call issued ; 


to the LAN Facility. 
A sequential file named "LANC-F" will be OPENed and read record by 


record. Each record will represent a directive. Directive names 
will be determined and the respective routine for processing that 
directive will be invoked. As a result of this processing, 


additional LAN data structures will be constructed and existing ones 
updated. The C-F will be required to be established by a system 
network administrator. It can be built using either MOD400's line 
editor or screen editor facilities, and it will be required to be 
named "LANC-F", It must reside under the >>SID directory. 


3.2 SUBCOMPONENT DESCRIPTION 


3.2.1 System Initialization Subcomponent 


The following 3 sections provide a description of the structure and 
processing logic in each of the 3 modules that comprise the LAN CLM 
bound unit. A 4th section describes the data structures generated 
and initialized by the LAN CLM function. 
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a i oad ‘ oy Boyt “YY foe ri 6 


( 3 : y) , 1 : 1 Root Mo aul e | aici es eee aa 


The root module contains no executable code. It is° simply, as 
previously mentioned in Section 3.1, a sequence of constants, 
displacements and pointers structured according to prescribed 
conventions. The central CLM function works within the structure 
to locate a match between a directive name read from the CLM USER 
file and one of the directive names contained in this root 
Girectory. When a match is found, floating overlay module #1 will 
be called to provide the processing for the respective directive. 

The structure and its elements comprising this root ‘module are 
described in Ref. l. This description is al so" provided* here for 


purposes of convenience. . Be 
ELEMENT DESCRIPTION = BRS 
1 (3 words) Name given to the LAN- directive’ “gtoup (in 
oo. 2. Ve eee Boas 
2 (2words) Represents lst ana ra’ ‘betaaeed: of”. decade 
year (in ASCII) __.... , 
3 (5 words) Month, day, time (in ASCIT) ; 
4 (1 word) Revision number Seer Poss age: 4 
( 5 (1 word) Displacement (bytes) | “to. “Device Descriptor 
Table 
6 (2 words) Pointer to work area for lst and 2nd 
overlays | — 
7 (1 word) Displacement (bytes) within the lst overlay 


to an initializing routine which will scan 
the System Device Table to detect presence 
of Lan Controllers and provide required 


processing 
8 (2 words) Size (in bytes) of interpretive overlay 
9 (2 words) Size (in bytes) of cleanup overlay 
10 (1 word) Control word 
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“4  Mo.99° (9 words). °"- | Link fields: ‘this: field is present in each . 
| root module for each CLM command group; . 


points to -the next ‘CLM root directory hae SS 
has been pices ae eae ne 


12 (variable) Made up of occurrences of command blocks, 
one for each LAN directive type processed 
by this CLM BU 


7120 (Lb word) . ‘End of ‘structure. ,séntinel 


oa é 
* Met ok oS 


14 (variable) Work area.’ 


ate reds See me & ‘ 
ie : ‘ me ~~ on “ 7 tony o 
— SP Pies eee a ee : aE Pe nico Pe OE ESN, 
° ory a OES he a eo ae 0 elas: Sangh abet Ake 
a Se : 7 ~ 
ean . 5 ah me yee am, be “5 ~ a : ie ee : 
. (aa , a " ; C ade, pe » 5 po! : a0 “rn os tt er “spay ie. hose 
oan whee , : HA \ : at 8 x 
:S ase “Module "os wer7 TN 6S" 
e * 


This module will be linked in the ZQLCLM BU as the lst of 2 floating 
“overlays:” It°wilt* ‘consist of eo functions: 


of fet are bot rh sto 


_., Bpitial izing Routine 
This routine eroviaes” “an initiakiz iaia function for the LAN command 
group. It will be executed once when the BU root is initially 
‘loaded. ~it will* access the System. Device Table of active devices 
configured on the megabus which was- previously constructed by the 
central CLM function. A scan of the directory is made to locate 
entries with LACS device ID's. The input device ID returned by an ~. 
active LAN Controller will be '2Ehh' where the 8 least significant | 
bits .of the ID word will specify acepees type and sub-channel ~ 

~~ number” (see Section- 3.4.:0f “Ref. °2)'. °° Because of the position of 

controklkéer “address:“and> “adapter nimiber in the 10 bit channel 
number, and the method in which combinations of channel numbers 
are generated, a total of 32 "2E" entries will exist in the Device 
Table for: each’ active LAN Controller configured on the megabus. 
Possible ‘error conditions that may be detected as a result of 
scanning the Device Table are: 


No LAN Controller is configured; 

No adapter is configured on the controller; 
Adapter type is not CSMA/CD; 

Adapter QLT's have not eeceuEce -DEOPS Eve 


ee Bal 


0oO0O00C- 


Any of the above error condi tions will result in setting a 

"reject" flag in the work’ area: ‘Processing of this directive will 
be terminated and subsequent directives will be rejected. No LAN 
structures will be generated and LAN functionality will not be 
invoked. 
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recorded: seo f 

- megabus address ‘efscoptrolier, 

—- count of active adapters,. ... 

~ adapter Poe ee enNay on Ee OnEE omnes 


( For each aaccaaariac ie pac the following. information is 


Layer Instance Directive Routine 


A scan of the-~parameters. supplied in the directive .will be 


performed. If parameter format is correct, the following 
processing sequence is executed: .«~ aS Gate. 


verify correct directive sequence, i.e., insure that this is 
the lst LAN directive, or that previous: dinective was an-LUSR 
directive; | 


“_ Pan Se aa wale a, va we . 
enor 4 ae om oEtPe 4 «. arate n 


phe: Rae 


verify that sepeioides shee ak ‘La. fee omask7 Sareneter matches ‘ 
controller configured on the megabus; 


ee uy 
calculate weight represented by “this ‘controtier “and its 
adapter(s) and call; pGGM function. B2Bbbi ves, ecizbor ald! 
ae Sa is 


obtain block of cee “memory ; to. “store off name “Of layer 


instance ane mnEer ENE level. auceian adt ora batur br 
| 3 Sol GO neve & weiszonu2 MID lerg.s: 
- 7 i DPE oa a, pee I: yal: a) Ge: Geet are 
( LUSR Directive Ro ut sine «4; 48 3G liiv le i ae on OO ak 


i er oie r ig i mt 


a 


A scan of the parameter: “values supplied. “with. this “directive will 
be performed. If =the parameter, -values ;, rane “anRcoPriate, the 
following sequence is executed: me Bey ele 


wits 


“£3 pes, ~~ ony 
4! ve DPN: paar ee e “t wey ‘ . 
a a a id es eu. i . » a 2 Wes 


verify correct directive ‘Sequence, i. we. “insure “that the 
previous directive was eee a layer instance directive Or an 
LUSR directive; 


Obtain a temporary memory block; link this block to the layer 
instance structure it belongs to, or to the previous LUSR 
structure; add 1 to LUSR count; 


store LUSR name and peaues task level; 


pas 


call CLM function 17-:f0 Teserve free Irn. 


“i wee ade, o 
io % tee $ . 
a © “et we oe - wv 


ee 
Rew r 
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3.2.1.3 2nd Phase Module 


This. module is. linked in the ZQLCLM BU as wae. 2nd of the 2 floating \—~ 
overlays. It is loaded and» invoked following the coupterson of Phase 
1 and Con's peas balancing processing. ea 


Bayer: Instance ‘pivective Routine as 


working: wie the temporary structures built a Phase 1 processing, 
this routine eens to execute the following steps: 

Get - permanent. “memory block, for" Se Controller Directory (CD) 

structure and. 'n' Controller Table “(CT)” structures where 'n' 

“ls. equals, -the number. of LACS. ‘Controllers’ “conf igur ed. Initialize 

ee the se. ‘structures and. link them together. 


oe Get . i: ‘permanent memory block: “for Uy. ‘Physical Line structures 
Sone ne O's be incorporated in a Phy sical Line Directory (PLD), where 
Voce. ov'n' equaks.the number Of. adapters | conf igured. Initialize these 
y uicts:. gtructures..and link,.. then “backward . to their respective CT 
ae. ¢i. eee ead re oe 
“For - Sach: ‘controller -configured, “get © “a oeqanent memory block 
for 'n' Layer Table (LT) structurés ‘where 'n' equals the number 
of different protocol layer types configured to reside in this 
controller. Initialize these structures and link them with 
their superior CT structure. 


For each LT configured, get a permanent memory block for 'n! ~ 
Layer Instance Table (LIT) structures where 'n' equals the 
number of layer instances configured within this protocol 
layer type. _ Initialize these structures and link them with 
their superior LT structure. 


For each LIT configured, perform the following: 


Get CPU # that this controller is assigned to by 
invoking CLM Function #22 with weight parameter set to 
ZeLKO} 


Determine if interrupt task level specified for this 
LIT is a unique value for this processor; if so, spawn 
an interrupt handler task at the level specified for 
the processor no. specified. 

If interrupt task level has already been installed, 
take no action. 
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( | LUSR Directive Routine | PHOS Soeaiees, ER: Te 


Again, working with. “the * “temporary structurés. built.by~ Phase 1 
processing, this roviti ne - ‘proceeds ‘to execute-‘the vigcuiciahaes ar aiet 
eS) ae 
Get a permanent memory block for in! local user ‘structures 
where 'n' equals the total number of: local: ‘users:ispecified in 
this configuration. . ,This collection of structures will be 
referred to as “the Uger. ‘Dire'ctory (0D). _Link ‘the’ UD: to: ‘the CT. 
eee sO: Bi ees 

For each LUSR. directive. processed during Phase 1, CLM. ‘Fanceien 
#11 is calléd, ‘to build af ‘RCT strivcture,2"and:if =the request 
level is a unique. val ite _ fOr; the” processor,’ # “TCB swikl also be 
generated by CLM.” : ; The ~-RCT “andy the PCB “structures will be 
initialized on returny” “For Trst- release, -the:- request task TCB 
will be set up to execute on the processor to which the 
corresponding LACS contyoliér “has”: ‘been “assigned. “2 In other 
words, the request task “that. is created “is for? a’ -_particular 
user who is interf ati ng= With ‘a Tayer “instance. - That layer 
instance is configuréd “to ‘e@xecute'in a& particulat:. ‘controller, 
and that controller has been assigned to a-:‘processor. It is 
this -.progessor that. the request task is set up to execute on. 


An LUSR ‘structure - within” the :UD “Ps - alse. sgh iaireceereta at this 
Mics Benes ca ee, ee 


ee 


Pe g 
3 oe £ SNe awe t £2 “rs “ is 1 me, st, andy os wh ret 
: ; a 8 = od ue a "ae! ‘ ig “Tb f 
i. . md . a $ : 1 Yene! moe oA ah oe + ed 
Re CMe a Og oe wb ey ae 
2 oe Pee ems hen : oe} Sty, Ss " 
at * we Sid ew ee Lact de alba ie’? aller one othe sos dh es Meee 
wa Wee ten Kee PE a tel hae! 
aor: ar ™ Fr, meet ’ 
Bee ete gs eg Se Ye Gee Soils Gee ee Le ees 
So ee ie sty nm oe aed ne t. care ws 
‘a eg Eee a Ot PE gy, ~m ‘ ca : 
< ‘ a ae ‘ - Has Pear uy " Reg . ~, F a A 
eo ee grit oes 4 oh Pee as he bas patie ‘ “ an vy ge ~ a Phd ad gees, 1 . 
: . on 7 2 . ‘ i we F 
| : ov He Nee le wate & Fy Mad ms Nast 
ice ee ae ed Te ae we ery ef 
*s Sr ee a oa 0 a ‘ , mee 7 ; Fae Ee Oe ad a e 
a -~ 8 " aa ra 3 oe 7 j 
‘ , Ans ce a oy as see? t be aed Tate bw ene a wo 
Ps i a, eae oa wo > ove f / 
: a SB etn * mo Z 
Oe a SP ss} HES CC £ ¥ a ng sey my se ey 
ead eve “had wn SoA t 
+ eet a, ; ‘ 
i 23 me sie a ee a ae pow 
wi ngs wed Bat one ak bone Ses Rd ae peeve ate ete ee 
a Rowe: ah and Tre 
Bug t oy vg rk yas ys 1 
‘ ey y gts “ 
& = ; ‘ yf vet " 
Le ene Bi axte . we Lt tre an See? 3 
nd sypn ie 
pre a . Sa ae 
wma ee tec? io 
r ¢ sme ute <7 
ee ae : 
K. 
vee 
soot MBs 
", 4 ten on , 4 
¢ . wey 1 pees 
yy "a beat olen &. be a ed? whe aw nd coy ee! \, wo s. om ‘3 { Si . Sool 
: i. a ¥ wan obs we ibs te 
A ¢ —, len od 4 a 
o oe Fey tease ne ers ioe 
-~— fel het bby oe wd i a 
nab ke op as 
* ram oe: Dad 
t rf % S yet se es Nees “ay j 
a > oe ya a ab we rd ET, C: : ‘ : on Dae 
“ss m rt Ae ove bee 
wee fae ee © ‘ . 
a 8 ges SB : “sy ~ Se 3 
ter Meu ert see odes aes ad 2S 
re se 
fer en yen. “t 
< anon 
wae d «, 5 ral x 
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3. 2. 2 Conf 1 S. ubcompo ne nt 


quration- Pile. Procéssing- 


The Sun CeLon of. processing. C=F diractivés will be provided by the 
module. described bélow. This module is linked as part ot the ZQLMGR 
BU. ZQLMGR is the L6 resident portion of the LAN System Management 
function. 


i 2. 2% 1 C-F ‘Processing Module 


The processing logic of this module imposes certain requirements 
on. the, C-F.. relating > to its. characteristics. It must be a 
sequential | file named "LANC-F", It must have been generated by 
MOD400' 8. Line. Editor or Screen Editor facilities; and it must 
reside ina specific directory - = assume 2>SID for now. 


This. file is processed. ‘using » File Management and Data aanaconene 


services. File Management | calls are limited to SGTFIL (get-file),. 


SOPFIL (open-file) . and... SCLPIL (close-file). The only Data 
‘Management call used is SRDREC (read-record). 


The c F will initieiiy be read in its entirety in order to make a 
lst pass over all the directives in the file. As a result of this 
lst pass, a.series of temporary data structures will be 
constructed, Following the necessary File Management calls to get 
and | open. the. file, successive directives will, be accessed by 
issuing. $RDREC. MCLs. “A large memory block will be obtained in 
which to construct the ‘temporary: data structures. 


For ‘Gach. Layer, ‘Shseande directive encountered, a temporary 
controller. block “structure is allocated, Each time a new 
controller | mask ‘parameter is. ‘recognized in an li directive, a new 
conhtrollér ‘block ‘structure is allocated. | 
For *éach. new. ‘type of: 1i- ‘directive, a layer instance array block is 
allocated ‘(Tayer ty pe pointer in controller block points to li 
array ‘block. ne 

For .. ‘each unique. layer instance number, an li structure is 
allocated. The - address” to this li structure is stored in the li 
array block. = - | 


For each local SAP directive belonging to a layer instance, a 


local SAP structure is allocated and chained off of its li 
:SELUCEUE.C | -previously | constructed. The parameters specified in the 
Te¢al SAP “directive. are- stored in the local SAP structure. 
“Processing. “for ‘remote “SAP ‘directives is practically the same as 
that. described above for local SAP's, — 


‘In ‘this. way, when end of file is reached, a hei rarchy of linked 


structures will have been constructed in a temporary storage area.. 


An important — result of this lst pass is that counts of relevant 
entities will have. been accumulated,  @.g., local SAP's, remote 
oa and: peaes instances. : 
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